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ABSTRACT 

This  paper  presents  an  approach  for  supporting  reactive  capability  in  an  object- 
oriented  GIS  database,  through  the  use  of  an  event  interface  comprising  an  event 
generator  and  rule  objects.  This  interface  supports  specification  of  events  spanning  sets 
of  geographic-feature  objects,  and  detection  of  primitive  and  complex  events.  Rules  can 
be  specified  to  apply  either  at  a  class  level  (i.e.,  to  all  instances  of  a  given  geographic- 
feature  class)  or  at  an  instance  level.  In  addition  we  allow  evaluation  of  both  pre-  and 
post-conditions  on  changes  to  a  feature.  This  approach  is  relevant  in  three  distinct 
situations:  (1)  immediate  mode,  to  execute  rules  immediately  before  or  after  some  state 
change;  (2)  deferred  mode,  to  execute  rules  at  the  end  of  several  changes;  and  (3) 
detached  mode,  to  perform  rule-based  actions  separately  from  the  state  changes.  GIS 
presents  a  rich  set  of  problems  for  which  this  approach  can  be  useful.  This  paper  outlines 
the  key  elements  of  the  rule-based  approach  employed  in  an  object-oriented  framework 
used  for  viewing  and  editing  Vector  Product  Format  (VPF)  source  data. 

INTRODUCTION 

A  joint  project  of  the  U.S.  Naval  Research  Laboratory  (NRL)  and  the  University  of 
Florida  during  the  past  two  years  has  resulted  in  the  development  of  an  object-oriented 
prototype  application  for  viewing  and  managing  Vector  Product  Format  (VPF) 
geographic  databases  (DMA  1993),  using  the  Smalltalk  language  on  a  Unix  platform.  As 
defined  by  the  Defense  Mapping  Agency  (DMA),  the  VPF  specification  uses  a  relational 
database  approach  for  storing  metadata,  feature  attributes  and  geo-spatial  information. 
However,  the  current  project  uses  an  object-oriented  representation  of  VPF  (OVPF)  to 
facilitate  complex,  user-interactive  operations  with  the  database  (Arctur  1995a,b,  Shaw 
1994). 

Building  on  the  literature  of  recent  developments  in  rule-based  frameworks  for  object- 
oriented  databases,  we  have  implemented  such  a  framework  in  our  Smalltalk  OVPF 
viewer/editor  application  to  help  in  managing  application-dependent  constraints  on 
changes  to  geographic  features  (e.g.,  preventing  the  user  from  creating  or  moving  a  land 
feature  over  water).  We  first  present  background  on  the  rule-based  framework,  then 
introduce  our  implementation  and  provide  an  example  of  usage. 

. .  . 


CONCEPTUAL  BACKGROUND 


Aciive  Ohiecis  and  Daiabases 

Dunng  the  past  years  database  management  systems  (DBMS)  have  undergone 
dramatic  changes  as  a  result  of  the  increasing  requirements  of  modem  day  applications. 
Conventional  record-oriented  database  systems  are  subject  to  the  Iiniiiaiions  of  a  finite  set 
I'f  data  types  and  the  need  to  nomiali/e  data.  These  limitations  have  led  to  the  evolution 
of  a  new  paradigm,  namely  object-oriented  database  management  systems  (ODBMS), 
which  offer  increased  modeling  power,  Ilexible  abstract  data-typing  facilities  and  the 
ability  to  encapsulate  data  and  operations  via  the  message*  metaphor.  Despite  the  ability 
to  model  complex  objccLS  and  relationships,  these  ODBMSs  still  lack  .some  of  the 
requirements  of  a  large  class  of  new  applications,  specifically  tho.se  requiring  monitoring 
of  siiuauons  and  the  ability  to  respond  automatically,  possibly  subject  to  timing 
v.onstraints. 

Active  dataha.ses  have  been  proposed  to  meet  some  of  the  requirements  of  non- 
iraditional  applications  (Chakravarthy  1994a).  Active  ODBMSs  extend  the  nomial 
functionality  of  ODBMSs  with  support  for  monitoring  u.ser-defined  situations  and 
reacting  to  them  without  user  or  application  intervention.  These  ODBMSs  continuously 
monitor  situations  to  initiate  appropnate  actions  in  response  to  database  updates, 
vvcurrence  of  panicular  states,  or  transition  between  states,  po.ssibly  wnihin  a  response- 
lime  window.  The  emergence  of  this  trend  of  active  ODBMSs  .serves  a  large  variety  of 
applications  such  as  CIS,  AM/FM,  computer  integrated  manufacturing  (Honnavalli 
1994),  process  control,  battle  management,  and  network  management.  Furthermore, 
active  databases  provide  an  elegant  means  for  supporting  integrity  constraints,  access 
control,  maintenance  of  derived  data,  and  materiali/.cd  views  and  snapshots. 

Active  behavior  is  by  no  means  a  new  notion.  However,  it  has  been  used  to  connote 
dilfercnt  behavior  in  various  contexts  within  computer  .science  Morgan  used  the  term 
'active  database,*'  perhaps  for  the  first  time  (Morgan  1983).  to  de.scnbe  a  system  that 
supports  automatic  update  ol'  views  and  derived  data  as  ba.se  data  are  updated.  In  the 
artificial-intelligence  community  the  term  "active  object"  is  u.sed  either  for  active 
knowledge  representation  and  inference  mechanisms  or  for  achieving  intelligent  behavior 
and  concurrent  compulation.  The  programming-language  community  u.scs  the  term 
"active  object"  in  order  to  structure  concurrent  applications  in  an  obieci-oricnted 
programming  language.  Ishikawa  u.sed  the  term  "active  object"  to  distinguish  real-time 
objects  from  others  which  have  timing  consU'aints  (Ishikawa  1990),  In  summary,  the  term 
■  active"  has  been  u.sed  to  convey  concurrency,  asynchronous  behavior,  and  parallelism  of 
active  objects,  intelligent  behavior  of  agent.s/actors,  or  active  capability  of  a  system.  In 
other  literature  similar  notions  arc  elaborated  wiihout  using  the  term  aciive  explicitly. 

The  key  distinction  we  draw  between  an  acti\e  and  a  passive  object  lies  in  an  active 
ohieci's  ability  to  monitor  its  state  and  lake  pre-defined  actions  that  are  ba.sed  on  the  state 
changes.  This  is  in  consirast  to  a  conventional  object  which  responds  to  a  mes.sage  with  a 


^.All  actions  perlormed  in  an  object-oriented  system  are  the  result  of  sending  a 
message  tti  an  object.  The  receiver-object  then  responds  by  executing  a  method  by 
that  name.  For  improved  readability  in  this  paper,  we  u.se  the  terms  message  and 
niethod  interchangeably.  However,  thc.se  terms  have  distinct  meanings:  i.e..  for  a 
given  message  there  may  be  one  or  more  methods  defined,  as  any  number  of  objects 
can  ha\e  a  method  wnth  the  same  name. 


predefined  effect  (of  course  based  on  the  state),  but  the  object  cannot  monitor  its  or  other 
objects'  status.  This  concept  (of  activeness),  to  some  extent,  is  present  in  the  actor  model 
of  Agha,etal.  (Agha  1986). 


Rules 

^les,  also  referred  to  as  triggers  and  alerters  (Chakravarthy  1989,  Dayal  1988, 
Dittrich  1986,  Su  1988),  have  been  proposed  to  provide  active  functionality  in  ODBMSs. 
Rules,  in  the  context  of  an  active  DBMS,  consist  primarily  of  three  components:  an  event, 
a  condition,  and  an  action.  An  event  is  an  indicator  of  a  happening  (either  simple  or 
complex).  Events  are  recognized  by  the  system  or  signalled  by  the  user.  For  example, 
even^  such  as  the  creation  of  an  instance,  the  change  of  an  attribute’s  value,  and  accessing 
an  attribute's  value  are  detected  by  the  ODBMS.  The  conjigon  specifies  an  optional 
predicate  over  the  database  state  which  is  evaluated  when  its  corresponding  event  occurs. 
The  conditions  to  be  monitored  may  be  arbitrarily  complex  and  may  be  defined  not  only 
on  single  data  values  or  individual  database  states,  but  also  on  sets  of  data  objects, 
transitions  between  states  of  materialized/derived  objects,  trends  and  historical  data. 
Actions  are  the  operations  to  be  performed  when  an  event  occurs  and  its  associated 
condition  evaluates  to  true.  Actions  can  be  programs  whose  execution  may  in  turn  cause 
other  events  to  occur.  Once  rules  are  specified  declaratively  to  the  system,  it  is  the 
system’s  responsibility  to  monitor  the  situations  (event-condition  pairs)  and  execute  the 
corresponding  action  when  the  condition  is  satisfied  without  any  user  or  application 
intervention.  The  advantage  of  using  rules  as  a  means  of  providing  active  behavior  is  the 
freedom  from  explicitly  hard-wiring  code  which  checks  the  situations  being  monitored  in 
each  program  that  updates  the  database. 


Events 

Incorporation  of  rules  in  any  system  entails  identifying  what  constitutes  an  event, 
developing  an  expressive  event  specification  language,  constructing  an  event  detection 
mechanism,  and  identifying  how  to  represent  conditions  and  actions.  Our  framework  is 
based  on  the  classifications  in  Snoop  (Chakravarthy  1994b,c)  which  defines  semantics  tor 
various  events  and  event  operators  in  an  object-oriented  environment.  An  event  is  defined 
as  something  that  happens  at  a  point  in  time.  In  an  object-oriented  context,  the  events  ot 
interest  are  concerned  with  changes  to  an  object’s  stale.  An  objects  state  changes  as  the 
result  of  an  update  operation.  Update  operations  occur  when  an  object  receives  a  message. 
Therefore,  we  view  each  message  sent  to  an  object  as  a  potential  event.  Considering 
messages  sent  to  objects  as  events  per  se  is  ambiguous;  it  is  not  clear  whether  the  event  is 
raised  before  or  after  the  execution  of  the  update  message.  To  resolve  this  ambipity,  the 
pre  and  post  clauses  are  introduced.  The  "pre"  clause  indicates  the  signalling  ot  an  event 
before  the  message  is  executed,  while  the  ’’post”  clause  indicates  the  signalling  ol  an 
event  after  the  execution  of  the  message. 


Events  are  categorized  as  being  either  primitive  or  complex.  Primitive  events  are  those 
signalled  at  the  beginning  or  at  the  end  of  execution  of  a  single  specific  message.  The  term 
beginning  refers  to  the  point  before  the  receipt  of  the  message  and  end  refers  to  the  point 
after  executing  all  operations  within  the  method  including  the  return  statement.  It  is 
important  to  note  that  messages  sent  to  objects  are  considered  as  primitive  events 
regardless  of  the  type  of  operations  performed  by  the  method. 

Many  applications  are  not  well  served  by  primitive  events  alone.  Complex  events  (also 
called  composite  events)  provide  a  simple  and  powerful  mechanism  for  expressing  the 
conjunction,  disjunction  and  sequence  of  either  primitive  or  other  complex  events.  In  our 
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framework  an  event  can  be  defined  as  the  ^  twcr^eais  El  and  E2  which  is 

signalled  when  both  El  and  E2  occur,  ^  ^  Haer  of  execution.  The 

disjunction  of  two  events  would  be  signalled  c.itK- El  or  El  occurs.  The  sequence 
event  would  be  signalled  by  completion  of  the  oconEace  of  a  set  of  events. 

Further  details  on  the  event  specification  langua^^’*  ^  -Q^^i^^tions  of  lemporally- 
complex  events  may  be  found  in  (Chakravarthy 

RULE-BASED  FRAMEWORK  /^®^-^fEVtAT10N 

The  foregoing  discussion  provides  a  basis  Uii  incrwudiK  lur  mplementauon  of  the 
rule-based  framework.  As  events  are  the  mosl  ^  ^  design,  we  will  Erst 

describe  event  objects,  then  describe  rule  objcc(.<»/  sample  of  usage.  We 

will  then  describe  the  outer  framework  in  which  iEeakniiiHf  rule  firing  take  place. 

Event  Objects 

Events  are  first-class  objects  in  this  frame iignificant  state  and 
behavior.  The  PrimitiveEvent  class  in  Figure  1  attribute  which  is 

inherited  by  all  its  subclasses.  For  each  new  ^  am?  sent,  this  attribute  is 

assigned  the  name  of  the  message  for  which  the  ^^^ised.  CompiexEvent  class 

defines  further  attributes  used  by  its  own  subclafl.*it^^ 

The  key  method  for  each  of  the  event  classes  1**  That  aitahod  takes  only  one 
argument  which  specifies  the  name  of  the  messfl^f^  an  event  to  be  raised. 

The  event  is  raised  when  the  object(s)  associalt^tl  object  receives  that 

message.  For  PrimitiveEvents  the  notify:  method  '^^®^P^**=^^guraent  to  its  ov,ti 
eventMsg  attribute  value  and  returns  tnje  if  they  niril*"  ^  ^^^^ciiComplexEvent  subclass, 
the  notify:  method  also  examines  a  particular  of  ifie  status  of  its  other 

attributes,  before  returning  true  or  false. 


Figure  1.  Event  Class  lUv'i'Arciy 


An  event  instance  is  typically  created  at  the  time  We  will  describe  the 

Rule  object  and  then  present  an  example  of  usage. 


Rule  Objects 

Rule  objects  have  the  structure  shown  in  Figure  2.  A  single  class  sulTiccs  for  defining 
ail  rules.  The  feature  attribute  may  be  assigned  a  pointer  to  either  a  single  geographic- 
feature  instance,  such  as  a  road  or  lake;  or  to  a  feature  class,  such  as  the  defining  class  for 


Rule 


feature 

event 

condition 

action 

action  Priority 
preOrPost 


Description  of  Rule  attributes: 

•  feature:  pointer  to  a  geographic-feature  class  or 
feature  instance 

•  event:  pointer  to  an  instance  of  PrimitiveEvent  or 
one  of  its  subclasses 

•  condition:  condition-test  method  name 

•  action:  action  method  name 

•  actionPriority;  integer  value  1  (low)  to  100  (high) 

•  preOrPost:  flag  specifying  if  condition  is  tested 
before  or  after  the  message  raising  the  event 


Figure  2.  Structure  of  a  Rule  Object 

roads  or  lakes.  In  the  former,  the  rule  will  be  applied  only  to  a  particular  instance  whereas 
m  the  latter,  the  rule  will  be  applied  to  all  instances  of  the  defining  class.  The  event 
attribute  is  assigned  a  pointer  to  a  specific  event  instance  (introduced  above),  which  could 
be  either  a  PrimitiveEvent  or  a  ComplexEvent.  The  condition  attribute  is  assigned  the 
name  of  a  method  to  be  executed  at  the  time  the  event  is  signalled,  which  will  return  true 
if  the  condition  is  met  and  false  otherwise.  The  action  method  is  then  executed  if  the 
condition  evaluates  to  true.  The  preOrPost  attribute  specifies  the  relative  timing  for 
execution  of  the  condition  method  with  respect  to  the  message  raising  the  event.  The 
condition  may  be  evaluated  either  before  the  event  message  is  executed,  or  upon 
completion  and  return  from  the  event  message  execution.  The  actionPriority  attribute 
value  is  used  to  help  mediate  in  situations  where  multiple  rules  fire  at  the  same  time. 


Example  Rule  and  Event  Objects 

An  example  of  a  Rule  to  prevent  any  BuildingPoint  geographic  features  from  being 
created  over  water  is  shown  in  Figure  3.  In  this  case,  the  Rule  is  associated  with  the 
BuildingPoint  class  and  thus  will  be  applied  to  all  instances  of  that  class.  Alternatively,  the 


condition 

action 

actionPriority 

preOrPost 


"T>"^$topCreateFeature') 


eventMsg 


C’newPoint:') 


Figure  3.  Example  Rule  and  Event  Objects 
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user  may  associate  the  Rule  with  a  particular  BuildingPoint  instance.  Due  to  the  setting  of 
the  preOrPost  attribute,  the  condition  method  onWaten  is  evaluated  before  the  Ev^t's 
eventMsg  (the  newPoinl;  method)  is  carried  out.  If  the  condition  method  onWater:  returns 
true,  the  action  method  stopCreateFeature  will  then  be  executed,  which  will  prevent  the 
eventMsg  method  newPoint:  from  being  performed.  The  actionPriority  setting  ensures 
this  action  will  have  highest  priority  among  any  other  Rules  which  may  also  fire. 

FeatureConstructor  Ohieci.s 

At  this  point  we  need  to  introduce  the  rest  of  the  framework  in  which  Events  are 
detected  and  Rules  are  fired.  In  the  OVPF  viewer/editor  tool,  all  changes  to  geographic- 
feature  objects  are  handled  through  the  use  of  FeatureConstructor  objects  (see  Figure  4a) 
OVPF  uses  a  construction-script  framework  with  a  state  machine,  supporting 
asynchronous  events  for  flexibility  in  working  with  runtime-dependent  constraints  on 
changes  to  a  given  feature.  This  framework  also  is  capable  of  extending  its  own  semantics 
at  runtime.  It  is  beyond  the  scope  of  this  paper  to  fully  describe  the  FeatureConstnjctor 
framework,  thus  a  very  simplified  portion  of  it  is  shown  here  for  discussion. 


Figure  4.  Key  Components  of  Event  Detection  Framework 


Wi*  reference  to  our  example  for  creating  a  new  BuildingPoint  feature,  we  assume  a 
Rule-Event  pair  has  already  been  created  (for  checking  if  a  new  point  feature  is  over 
water)  and  stored  in  VPFFeature’s  RuleBase  (Figure  4b).  This  rule  base  is  actually  a 
persistent  collection  held  in  the  ODBMS;  its  reference  in  VPFFeature  is  provided  for 
convenient  access  at  runtime.  The  following  sequence  of  events  could  then  take  place  at 
the  user’s  initiation  (step  numbers  correspond  to  those  in  Figure  5): 

1 .  The  user  chooses  the  appropriate  OVPF  menu  option  to  add  a  new  geographic 
feature,  and  selects  BuildingPoint  from  a  list  of  available  feature  classes. 

2.  The  OVPF  graphical  user  interface  (GUI)  creates  a  PointFeatureConstructor. 
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Action  Summary 


Direction  of  Messages 


I .  User  chooses  menu  option  to  add  a 
new  feature  _ _ 


GUI  creates  a  constructor  for  the  new 
feature  object _ _ _ 


Constructor  creates  a  default 
instance  of  BuildingPoint,  and 
requests  coordinate  point  from  GUI 


GUI  returns  user-defined  location 
coordinates  for  new  feature 


Constructor  sends  message  - 
feature  notify:  'newPoint:' 
argList:  (point) 
preOrPost:  'pre' 
from:  self _ _ . 

''e.  Feature  scans  rule  base  for  rules  with 
event  message  'newPoint:' _ ^ 


Feature  finds  rule  and  evaluates 
condition  message  -- 
constructor  perform:  onWater.  , 
constructor  then  queries  ODBMS  and 
returns  true  or  false _ _ _ _ — ^ 

If  condition  evaluates  true,  feature  ^ 
sends  message  -  I 

constructor periorm:  stopCreatefeatur^ 

^9  If  constructor  has  to  stopCreateFeatur^ 
then  constructor  assigns  ’stop’  value  to  1 
its  nextAction  attribute  _ / 

^ 10.  If  constructor’s  nextAction  is  ’stop’  it  A 
.  discards  the  new  feature _ y 


1 .  If  constructor’s  nextAction  was  not  ’stop^ 
then  it  sends  the  message  -- 
feature  newPoint:  point 
and  finally  inserts  the  new  feature  in  the 
quadtree.  _  ^ 


Figure  5. 


Flow  ol  Control  and  Behavior 


For  Rulc-Fvcni  Example 


3.  The  Constructor  creaics  a  dclauli  BuildingPoint  (caiurc  ohtcci,  and  iniiiaics  a 
request  to  the  GUI  lor  a  user-selected  location  coordinate  point,  to  be  returned  via 
the  point  1 :  message 

4.  On  insiruLiion  Irom  the  GUI.  the  user  chooses  a  location  on  the  map  with  the 
mouse,  and  the  GUI  returns  it  as  the  argument  in  the  pointi;  mo.ssa^e  to  the 
Constructor. 

Within  iLs  pointi:  method,  the  Constructor  notihes  the  new  BuildingPoint  leaiure 
instance  ol  an  impending;  Event  via  the  parameterized  notify:argList: 
preOrPost:from:  me.ssa^e. 

6.  The  new  BuildingPoint  object  cxceuies  the  inherited 
notify:argList:preOrPost:from:  method,  which  eheek.s  the  rule  ba.se  I'or  all  Rule- 
Event  pairs  whose  eventMsg  matches  the  notify:  argument,  in  this  case  newPoint: 

7.  II  a  matching  Rule-Event  pair  is  found,  then  the  Rule's  condition  value  (onWaler:) 
IS  sent  as  a  message  to  the  Constructor  lo  perform.  The  Constructor’s  on  Water: 
method  checks  the  database  lor  any  water-related  features  within  a  eiven 
tolerance  ol  the  user-sclccicd  coordinates,  and  returns  true  or  false  By  user's 
prelerence.  this  check  can  be  performed  either  on  just  the  features  currendy  being 
displayed,  or  on  feaiurcs  from  all  coverages  in  the  ODBMS. 

8  1}  the  onWater:  method  returns  true  (coincident  water  feature  was  found),  the 

Rule's  action  message  is  then  sent  to  the  Constructor.  In  this  ca.se  if  water  features 
were  lound.  the  message  stopCreateFeature  would  bo  the  action  message  sent  to 
the  Constructor.  Note  that  in  the  present  framework,  all  applicable  conditions  arc 
evaluated  bclore  any  actions  arc  pcrlormed.  If  multiple  conditions  return  true, 
their  action  mc.ssages  are  .sent  to  the  PointFeatureConstructor  in  order  of 
decreasing  actionPrionty. 

d  11  the  Constructor  receives  the  message  StopCreateFeature.  it  will  set  ns 
nextAction  aiinbutc  to  'stop'. 

10.  Upon  eompleiion  of  all  applicable  conditions  and  actions,  the  new  BuildingPoint 
object  returns  Irom  executing  the  notify:argLisl:preOrPost:from:  method.  'I'hc 
thread  ol  control  reverts  to  the  Constructor's  pointi:  method,  which  then  checks 
ns  nextAction  setting  It  n  is  stop  then  the  new  delauh  BuildingPoint  feature  is 
drscarded.  and  control  returns  to  the  user  wnh  a  de.scnptive  dialog  mes.sagc 

II  II  the  nextAction  is  not  'stop'  then  the  Constructor  sends  the  newPoint:  messaee 
to  the  new  BuildingPoint.  in.seris  it  in  the  spatial  quadtree,  and  presents  the  u.ser 
With  a  dialog  window  to  liil  in  any  BuildingPoint  feature  aiiribuies  needed 

S I M  M  A  R  V  A  .\  I)  P  R ( )S P FT  TS 

{  he  (iI.S  held  prc.senis  a  rich  .set  ol  problems  tor  which  this  approach  can  be  useful  It 
jn  be  used  in  three  distinct  situations:  ( t )  {nwwdtatc  to  execute  rules  immediately 
f  iore  or  aliei  some  state  change:  {2)  (lefern’d mode,  to  execute  rules  at  the  end  of  several 
hangos:  and  (.M  deiaehed  mode,  to  perform  rule-based  actions  separately  from  the  state 
hanges  Fuithermore.  ii  has  the  advantage  over  iradiiional  inference -engine  approaclies 


Oku  U  W.ll  wuh  an  arburanlylaryc  dau.bas.  of  pcrs,s.o,u  oh, ecus,  rather  than 

hL'ine  limned  to  those  ohiecLs  which  can  lit  in  meniois 

The  rule.evcnt  Iramework  and  procedures  were  stirprisinely  simple  to 

rule  proccssin^y^stcm  ^  operations.  An  important  benelit  ol  this 

S;i::rie:ted  .ramework  is  the 

pirrr::;;:  -  sy=;n:;=^  -  --  -  ---  -- 

runiime. 

The  desien  presented  here  is  easily 

modity,  dcleici  10  gcographiL-lcaiurt  o  jci  .  -  ^  ^  si^nihcani  advaniage  over 

aiinbuic. 

There  are  a  number  o.  issues  related  to  supporting 

===:li§i=£E=^ 

sample.  RKtherrhy  yielding  an  infinite  loop, 

B,  suppose  r^leR.  s  ac  10,^  ^  a  nu'Chmiism  for  establishing  the  consistency  or 

From  this  scenario,  it  is  c  .,,.iive  system  This  involves  writing 

correctness  o.  rules  must  he  an  inherent  p^^ir  ‘  ^  ,,hich  dynamically 

aleoruhms  which  statically  detect  rule  contl.cts  ‘'•"J  ,,  ptirsuine 

detect  problems  such  as  infinite  rule  triggering  We  aic  ,n  the  carls  sta.c,  i 

these  next  steps 
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